How to set up your server on The OneNet™ Member Network using version 2.5 of FirstClass™
First, we'd like to apologize for not getting this information to you before now. We were hoping that we'd be able to get this together sooner, but it wasn't to be. One of our key folks left the OneNet Board of Directors and without his help, and some other outside forces beyond our control, we fell behind where we wanted to be.
We also would like this to be more complete. Hopefully the information provided below will be enough to keep us from any major problems in the intitial stages of upgrading the network to the 2.5 version of FirstClass™.
Steve Asbury was kind enough to give us a set of recommendations on how to set up the OneNet using 2.5. We've decided that, for the time being, we are going to follow his primary recommendation (see #1 below).
Also, for now, we will hold off on the optional recommendations (see number's 2-4 below), but we hope to implement them over the coming 2-3 months-if appropriate. All regional hubs should strictly observe this in order to maintain the integrity of the overall OneNet Member Network.
We would like to ask that all OneNet Member Network systems agree not to export their directories, or the directories of any gated systems into the OneNet Member Network backbone (i.e. the backbone means the primary server in Boulder, and all Regional and Acting Hubs).
This means, simply, that you have directory sync turned OFF when gatewaying with any system that connects directly with the primary OneNet server in Boulder, or a OneNet Regional Hub system. It also means that all regional hubs have the Dir. Sync feature turned OFF when gatewaying with the primary hub in Boulder and any system gating with other systems on the OneNet Member Network (i.e. pretty much everyone except, possibly, some private systems the regional hub may be gating to).
Assuming the above recommendation is fully complied with, we would like to see all regional hubs upgrade to the 2.5 version of FirstClass™ at their convenience.
Thank you all for your cooperation in this.
Again, it is important that you follow this essential guideline. Failing to do so will almost certainly cause very serious network wide performance problems and highly excessive gateway costs.
1) That all OneNet participants agree not to export their directories, or the directories of any gated systems into the OneNet backbone.
2) Optional. It is permitted to export a very small controlled group of names from your system into the backbone, with the group not to exceed __ names per system. (e.g. 10). Members of this group should be restricted to significant contributors such as the Owner of the system (real name, as opposed to "Administrator" - see (3) below)., any sub-admins, OneNet board members etc. This can be accomplished by creating a privilege group (say "OneNet Directory Export") and adding selected users to it. The group is then entered on the gateway settings form in the "Export Users in Group:" field. The union of all these sets will be carried on the OneNet backbone, and replicated into each regional hub. Feeds from a regional hub will have the option of picking up this directory information.
3) Consider whether "Administrator" should be exported. The effects of this would be that each system will have hundreds of Administrator,xxxxxx entries. This can be easily controlled by not putting the Admin in the "Directory Export" group.
4) If a local regional group wishes to full exchange their directories, they may do so, but they will not be permitted to export any directory information into the OneNet backbone, because the dir sync cannot selectively pass information across multiple sites. In other words they may not participate in option (2) above. They may still receive the selectively exported names from the OneNet backbone.
